과제 체크포인트

필수 스펙

1. 반복 유형 선택

• 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
• 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
  • 31일에 매월을 선택한다면 → 매월 마지막이 아닌, 31일에만 생성하세요.
  • 윤년 29일에 매년을 선택한다면 → 29일에만 생성하세요!
• 반복일정은 일정 겹침을 고려하지 않는다.

2. 반복 일정 표시
   • 캘린더 뷰에서 반복 일정을 아이콘을 넣어 구분하여 표시한다.
3. 반복 종료
   • 반복 종료 조건을 지정할 수 있다.
   • 옵션: 특정 날짜까지
     • 예제 특성상, 2025-12-31까지 최대 일자를 만들어 주세요.
4. 반복 일정 수정
   1. ‘해당 일정만 수정하시겠어요?’ 라는 텍스트에서 ‘예’라고 누르는 경우 단일 수정
      • 반복일정을 수정하면 단일 일정으로 변경됩니다.
      • 반복일정 아이콘도 사라집니다.
   2. ‘해당 일정만 수정하시겠어요?’ 라는 텍스트에서 ‘아니오’라고 누르는 경우 전체 수정
      • 이 경우 반복 일정은 유지됩니다.
      • 반복일정 아이콘도 유지됩니다.
5. 반복 일정 삭제
   1. ‘해당 일정만 삭제하시겠어요?’ 라는 텍스트에서 ‘예’라고 누르는 경우 단일 수정
      1. 해당 일정만 삭제합니다.
   2. ‘해당 일정만 삭제하시겠어요?’ 라는 텍스트에서 ‘아니오’라고 누르는 경우 전체 수정
      1. 반복 일정의 모든 일정을 삭제할 수 있다.

기본 과제

공통 제출

• 테스트를 잘 작성할 수 있는 규칙 명세
• 명세에 있는 기능을 구현하기 위한 테스트를 모두 작성하고 올바르게 구현했는지
• 명세에 있는 기능을 모두 올바르게 구현하고 잘 동작하는지

기본 과제(Easy)

• AI 코드를 잘 작성하기 위해 추가로 작성했던 지침
• 커밋별 올바르게 단계에 대한 작업
• AI 도구 활용을 개선하기 위해 노력한 점 PR에 작성

기본 과제(Hard)

• Agent 구현 명세 문서 또는 코드
• 커밋별 올바르게 단계에 대한 작업
• 결과를 올바로 얻기위한 history 또는 log
• AI 도구 활용을 개선하기 위해 노력한 점 PR에 작성

심화 과제

• 모든 질문에 대해 꼼꼼하게 정리했는지

과제 셀프회고

모든 것을 AI에게 위임하지 말자

과제 초반에는 "나보다 AI가 더 똑똑하니깐 AI한테 알잘딱으로 만들어 달라 해야지 ~" 라는 생각을 가지고 과제를 진행했습니다.
그로 인해 생겼던 문제점은 AI가 결과물은 내주는데, 이 결과물이 올바른 결과물인지 판단하기 어렵다는 것입니다. AI가 내는 결과물을 검토하는 절차가 중요하다는 코치님의 말씀에 어긋나는 행위를 하고있었습니다. 이는 코치님과 페어 프로그래밍 과정에서도 드러난 문제점이었습니다.

저는 문제를 해결하기 위해 작성된 에이전트 코드를 삭제하고 처음부터 에이전트를 다시 구현하는 것을 선택했습니다. 에이전트를 재구현할 때 명심했던 부분은 "내가 해당 에이전트에게 어떤 일을 시킬 것이며, 어떤 결과 값을 받아내고 싶은지" 입니다. 이를 명확하게 설정하고 에이전트를 구현하니 에이전트가 내는 결과물에 대해 올바른 결과물인지 판단하기 수월해졌습니다.

하지만, 오케스트레이션 에이전트를 구현할 때는 어려운 부분이 많았습니다. 지금도 제 오케스트레이션 에이전트는 제가 의도한대로 동작하지 않아 고민이 많이 됩니다. 분명히 작업 플로우와 각 단계에서 사용해야 할 에이전트를 명시 했음에도 불구하고 제가 의도한대로 동작을 하지 않으니 참으로 답답합니다.

결국 과제는 각 에이전트에게 제가 직접 업무를 부여하는 식으로 진행했습니다. 과제 피드백을 통해 코치님들의 오케스트레이션 에이전트 구현 노하우를 여쭙고 제 에이전트에도 반영하여 잘 동작하는 오케스트레이션 에이전트를 만들고 싶습니다.

AI라곤 GPT에게 "이거 어떻게 해결해?" 와 같은 질문을 던지는 방식으로만 사용했던 저에게 해당 과제는 AI 활용의 폭을 넓혀주었고 AI 진입 장벽을 낮춰준 과제였습니다. 상당히 의미 있었고 꼭 과제를 완수하고 싶었지만, PR을 작성하는 현재 시점에서 테스트 코드 자체가 실행이 되지 않는 문제를 마주쳐 이를 해결하는 데 시간을 많이 사용하고 있습니다... 해결 !!!!!!!!!!!

ps. 명시한 동작대로 행동하지 않은 에이전트에게 정말 화가 많이 나더라구요... 테스트 코드 작성 에이전트에게 체크 리스트를 주고 판단하도록 했는데 테스트 코드 실행 자체가 안되고 있는 것을 왜 그냥 넘겼을까요....

기술적 성장

프롬포트 작성법

이전 : 에러 코드 던진 뒤 "이거 어떻게 해결해?"
현재 : ~~한 코드를 작성했더니 ~~한 결과물이 나왔어. 내가 원하는 방향은 ~~인데, 현재 코드의 문제점이 무엇이며 어떻게 수정해나갈 수 있을까? (any 타입은 절대 사용하면 안되고, 등등의 제약조건 혹은 필수로 했으면 좋겠는 부분 명시)

AI에게 원하는 답변을 얻기위한 프롬포트 작성법에 대해 익힐 수 있었습니다.

AI에게 모든 것을 위임하지 않기

AI에게 모든 것을 위임하는 것은 바람직하지 않다는 생각을 가질 수 있게 됐습니다. 또한 AI가 낸 결과물이 올바른지 판단할 수 있는 지식을 쌓는 것 또한 중요하다는 것을 알 수 있었습니다.

코드 품질

기능에 대한 스펙 문서 구조화 및 저장

• 필요한 기능에 대해 1차적으로 기능 상세 문서를 작성하고 이후 세세한 story로 작업 단위를 나누는 작업을 진행했습니다.
• 각 단계에서 작성된 문서를 프로젝트 내에 동일한 구조로 저장될 수 있도록 했습니다. (명확한 input과 output 제공!)
• 따라서 AI가 필요한 기능에 대해 제대로 이해하고 작업 단위를 분리했는지 개발자가 파악할 수 있고, 이후 테스크를 나누는데 도움이 될 수 있도록 했습니다.

범용적인 에이전트가 아닌 TDD 프로세스에 특화된 에이전트 구현 목표

과제 초반에는 만능 에이전트를 만들고 있는 느낌이 강했는데, 프로젝트 특성에 맞게 TDD Flow에 특화된 에이전트를 구현하고자 했습니다.
따라서 제 에이전트는

• 필요한 기능에 대한 기능 상세 문서 작성 에이전트
• 기능 상세 문서를 토대로 세세한 story로 작업 단위를 나누는 에이전트
• 테스트 코드 설계 및 작성 에이전트 (TDD Red)
• 테스트 코드를 통과하는 기능 코드 작성 에이전트(TDD Green)
• 작성된 기능 코드 리팩토링 에이전트(TDD Refactor)

로 이루어져 있습니다.

학습 효과 분석

• 명확한 프롬포트 없이 "어떻게 해결해?" 와 같은 대화 형식으로만 사용해왔던 AI에 대해 잘 사용할 수 있는 방법에 대해서 배울 수 있었습니다.
• 어렵게만 느껴졌던 AI 에이전트에 대한 진입 장벽을 부수는 계기가 되었습니다.
• AI를 잘 활용하는 개발자로 한 걸음 다가갈 수 있었습니다.

과제 피드백

최근 가장 핫한 주제인 AI에 대해 진입 장벽을 낮추고 미래에도 유용하게 써먹을 수 있는 기술에 대해 학습할 수 있었습니다. 너무 유익했어요 !

리뷰 받고 싶은 내용

1. 오케스트레이션 에이전트의 이상적인 구조

## 워크플로우 구조

```
사용자 요구사항 입력
    ↓
[1단계] Doeun (Epic 작성)
    ↓ "체크리스트 확인했니?" → ✅ → Git Commit
[2단계] Taeyoung (Story 분리)
    ↓ "체크리스트 확인했니?" → ✅ → Git Commit
[3단계] 각 Story별 TDD 사이클:
    ├─ Haneul (테스트 작성)
    │   ↓ "체크리스트 확인했니?" → ✅ → Git Commit
    ├─ Yeongseo (기능 구현)
    │   ↓ "체크리스트 확인했니?" → ✅ → Git Commit
    └─ Junhyeong (리팩토링)
        ↓ "체크리스트 확인했니?" → ✅ → Git Commit
    ↓
최종 결과 보고
```

위와 같이 오케스트레이션 에이전트(Jaehyun) 에게 명확한 워크플로우 구조를 제공했음에도 불구하고 각 에이전트의 문서를 확인 후 자기가 작업을 진행하는 것 같았습니다. 에이전트 정의를 md 파일로 해서 에이전트의 존재 유무를 파악하지 못하는 걸까요 ?

에이전트 정의 문서에 명확한 워크플로우 구조를 제공했음에도 의도한대로 동작하지 않는 경우가 많았는데, 코치님이라면 각 에이전트가 md 파일로 작성되어 있을 때 오케스트레이션 에이전트를 어떻게 구성하실 것 같나요 ?? 코치님의 노하우를 얻어가고 싶습니다 :)

2. 항상 동일한 구조의 결과물을 내기 위해선 ?

현재는 각 에이전트가 항상 동일한 결과물을 제공했으면 해서 각 에이전트마다 출력 구조를 명세하고 있습니다. 그럼에도 불구하고 가끔씩 자기 멋대로 결과물을 도출하는 경우가 있는데, 항상 동일한 구조의 결과물을 만들어 내는 것은 한계가 있는 부분일까요?

• 필요한 기능에 대한 기능 상세 문서 작성 에이전트, 기능 상세 문서를 토대로 세세한 story로 작업 단위를 나누는 에이전트 와 같이 md 문서를 작성하는 에이전트의 경우 대부분 동일한 구조의 결과물을 잘 뽑아내주고 있습니다.
• 기능 구현 or 코드를 작성하는 에이전트의 경우 명시해준 구조와는 다른 구조의 결과물을 출력하는 경우가 있더라구요... (ex. 명시된 커밋 컨벤션을 따르지 않는 경우, 테스트 코드 실행 해달라고 했는데 무시하는 경우, 결과 보고서 작성 구조를 따르지 않는 경우 등등)
  • 코드 작성의 경우 항상 동일한 구조로 코드를 짤 수 없으니 필연적으로 동일한 구조의 결과물을 도출하기 어려운 것이겠죠..?
• 에이전트 정의 문서에 출력 형태를 직접 작성하는 것이 아닌 별도의 출력 구조 정리 파일을 생성하여 관리하는 것이 좋은 방법일까요?